POV：你手上有一個跑在 Spot VM 上的 web 服務，機器隨時可能被收回，Cloud Run 的文件看起來就是為你寫的，你已經打開 console 準備建第一個 service。

昨天畫了決策樹，今天講一次我真的走完它的經驗。主角是 liaostudio，我的影片字幕工作流：上傳影片、抽音軌、產繁體中文字幕。它目前跑在那台 Spot VM 上，用 systemd 顧著。2026 年 8 月我認真評估過把它整個容器化搬去 Cloud Run，最後的決定是：暫不搬。這篇把評估表和理由攤開，因為決定不做的理由，通常比決定做的更值得記下來。

為什麼會想搬

起點很單純。它是一個 web 服務，有 HTTP 入口，聽起來就是 Cloud Run 的典型案例。加上那台 VM 是 Spot、會被收回，我想要不用管機器的部署方式。用 Day 16 的決策樹走一遍：Q1 看起來是「有人叫才動」，Q4 我想少顧一點東西，初步判斷指向房間 2。

而且我手上有 GCP 的 credit，成本是選型的第一考量，但也希望保留之後能擴的空間。Cloud Run 兩邊都沾到，看起來很合理。

評估表

表裡的數字（32 MiB、22 MB）是 8 月評估當時記下的。官方 Quotas and Limits 頁寫的是 HTTP/1 request 的上限，用 HTTP/2 server 不受此限；但那代表另一輪改動，評估時我把它當成一道硬牆來看。

為什麼決定暫不搬

把表填完，結論自己浮出來：

1. 我想解決的問題，搬了也沒解決。 「重開機自動跑起來」systemd 已經做到了，Cloud Run 不會讓它更好。
2. 會撞到具體的牆。 32 MiB 的 request 上限不是理論問題，我的上傳體積就貼著它走。前端已經用 wasm 壓過一輪，再往下就要改架構，例如改成直傳 GCS 再回頭通知 server。
3. 架構不是為 Cloud Run 設計的。 POST 立刻回 job_id、背景 thread 繼續跑、結果放在記憶體裡的 dict，這種寫法在單 VM 上可以運作，到 Cloud Run 就變成枷鎖：要嘛把狀態外部化（多一個元件要顧），要嘛鎖單一 instance（那搬去幹嘛）。
4. 真正的痛點是另一件事。 VM 被收回後不會自動重開，這才是我在意的。但它有自己的解法，後來用 Cloud Scheduler 每 5 分鐘把 TERMINATED 的 VM 拉起來（Day 18），不需要靠搬遷。

我從這次評估學到的

決策樹 Q1 我一開始答得太快。liaostudio 看起來是「有人叫才動」的 web 服務，但它有背景轉寫工作、有記憶體裡的狀態；回頭看，我現在的解讀是它更接近「一直在」，這是我事後整理時的詮釋，不是評估當時就寫下的結論。但至少可以確定：Q1 這一題沒答準，後面的計費和擴縮假設就跟著歪掉。

第二個學到的：暫不搬不等於永遠不搬。評估表留著，限制條件和算過的權衡都記錄了；哪天前端架構改了、或狀態外部化了，直接從那份紀錄接著做，不用重評一輪。

第三個：這篇講的是 Cloud Run，但同一張評估表把最右欄換成 GKE，大部分問題還是一樣要問，重開機、狀態、計費、你到底想解決什麼。Week 5 會做這件事。

明天講那台 VM 真的重開的那次：容器回來了，我自己寫的還原腳本沒有。

今日一句話

先寫評估表再決定。我以為要搬去 Cloud Run 的服務，填完表才發現真正的問題根本不在部署方式上。

延伸閱讀

• Cloud Run 官方：Cloud Run Quotas and Limits
• Cloud Run 官方：Billing settings for services
• Cloud Run 官方：Set minimum instances for services